I’ll start by saying that this is not a rant, but rather a cry of despair that I’m repeating and that slowly – but steadily – seems to come to consciousness in our industry, like this one. The phenomenon I’m about to describe is not only limited to the Javascript community either, that community seems a lot more affected than others.
Up until this morning, I had been mumbling about those concerns mostly to myself, and to some colleagues and friends. Then I read this article and I felt like I had to do something. This really is a good read, if you haven’t seen it yet, I recommend adding it to your reading list or Instapaper or whatsonot right away. The article, A generation lost in the Bazaar, talks about Unix and how the lack of overall design or “bazaar” mentality (depicted in The Cathedral and the Bazaar) have made it extremely hard to get anything done without digging through a jungle of libraries that kind of repeat functionality, contain copy-pasted code, or depend on libraries that they perhaps don’t need at all.
Incidentally, I just come back from a trip to Morocco, and I’ve been to the Souk in Marrakesh. Some of the Souks are extremely tourist-oriented: everyone tries to sell you their stuff (which is colorful and shiny) – and every few stalls or so you find about the same things.
See, there is a dark side to the bazaar. Imagine you are a newcomer to Javascript development these days. Which librairies should you pick to get started? No, wait, which package manager should you pick to get started?
"What's bower?"
"A package manager, install it with npm."
"What's npm?"
"A package manager, you can install it with brew"
"What's brew?"
…
— Stefan Baumgartner (@ddprrt) November 5, 2014
Granted, this won’t stop you from getting into Javascript. Once you have chosen which of the frameworks to go with, and after some time getting used to the quirks of the language itself, chances are that you will be productive. Or will you?
My experience has been that the super-fast code and refresh cycles make for a very gratifying experience: change something small, see the result right away. When you’re more on the pragmatic side of things, this is very useful and you can get something up and running quite quickly. There is, however, a price to pay to the approach of coding through instant gratification.
First of all, there’s the the trap of getting caught up in speed. It is one thing to get to a reasonable functionality in a short time, and another one entirely to build a piece of software that can be maintained or worked with in a team over an extended period of time. It is all too tempting to leave working code as-is, withouth refining it or improving it in a timely fashion. And before you know it, someone else has picked it up, or you yourself have picked it up again, copy-pasted it (god forbid!) or increased its complexity where there would have been a simpler solution would you have given it some more thought.
The second issue with “the speed” is that there are no natural pauses to stop and have a chance to think about the code that has just been written down frantically. Yes, interruptions are annoying and counter-productive – but I believe that correctly timed interruptions are very useful as well, because they give us programmers a chance to step away from the keyboard and use our brain for a minute. Of course, we are also using our brains while we write code – but give it enough time and practice, and much of the code or algorithms one writes down in our profession are written out of habit rather than out of carefully consideration.
Some of my best code has been “written” away from the keyboard, on a piece of paper or on a whiteboard, and only after iterating it for some time did I take the step to input it in the computer. I wish it always was like this. Much of my days are spent in front of the computer rather than away from it, even when I sense that what I’m doing is not the most productive thing there is. There is an expectation, I think, that “computer people” should sit in front of a computer. And if they don’t, it must be because they are not working. I don’t know to which extent this holds true in the creative working places à la Googleplex, but it certainly is the case in many offices around the world. The culture, it would seem, goes in favour of encouraging the production of lines of code over the production of a carefully crafted design.
Lastly, combining a quick iteration cycle with a seemingly infinite amount of libraries makes for a very dangerous mix. Everything is just one bower install oh-my-shiny-library away. The hardest thing in Javascript development today is maybe less the development itself than knowing which libraries to pick. It is very hard to tell which one will still be actively maintained a few months (or even weeks) after having added it to your project. This is where things are worse in Javascript-land than in any other community: much of the libraries out there are small experiments rather than side-projects meant to last for a bit. Yet other communities also have tools that provide the “fast reload” approach to coding, but don’t suffer from the same insane amount of libraries to pick from. Why?
Let’s go 15 years back in time. In the article that triggered me to write this entry, Poul-Henning Kamp makes the argument that the dot-com boom led many people without a formal CS education to get in and “just hack it”, and that the lack of formal education is in part at the origin of the lack of quality we see in software today. To be honest, I’m unsure about the formal education bit – I like to believe that with enough self-discipline, drive, and humility, it is possible to get good at it as well. But I would agree that the lack of perspective provided by a formal education in combination with everyone running around and screaming “just hack it” is not necessarily a recipe for success.
Fast-forward to today and to our jungle of half-dead Javscript libraries (I don’t want to call it zombie army just jet but we probably are not too far away). What happened? We are now in another bubble period with great opportunity for people in the IT industry, and we want to have as many people as possible join the party! Everyone should code. And we have made it so easy! Create a GitHub account, watch some of the many, many tutorials out there, and get going! Yay!
The sad truth is that something essential gets lost in all of this everyone-can-do-it-yay-lets-all-code euphory. I’m not exactly sure how to call it, so I’m going to pick something that is close enough to describe what I mean. I’m talking about craftsmanship. There is something to the pride of quality, the “work well done”, the “love of the craft” that is not communicated through the plethora of online courses and Learn To Code In One Week-End hackathons. This bit of pride and self-restraint is what I believe is lacking in the Javascript community. Instead of contributing to existing libraries, everyone wants to start their own and show the world that they, too, can code. It is Torvald’s “Release early and often” without the community smashing the ego of anyone publishing sub-par code.
Not everyone should code. Not every week-end project should be made public and available through Bower. The Javascript community needs to learn to filter itself. But that’s more easily said than done. There are so many people active in this community, nobody really knows whom to listen to. There is to the best of my knowledge no “Torvalds of Javascript”. Worse yet, “role models” (that can attract enough attention) such as the once very popular AngularJS framework pull a Google and declare that they’re going to be entirely backwards-incompatible with their next release, leaving thousands of developers out there wondering what tool to pick until the next release is out, and fueling and attitude wherein the well-being of the developers of a tool, not the one of the users, is most important.
I know it’s easy to critizise. But given the seemingly ever-increasing popularity of Javascript, if we don’t want to be flooded with IT job ads in 10 years time be along the lines of “Looking for Javascript developer to maintain legacy project depending on 36000 unmaintained NPM modules”, we need to do something. And the first step, perhaps, is to start by raising awareness. I hope this post will help with that.
